home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / doors_2 / ooiitour.zip / OOIITOUR.DOC
Text File  |  1992-01-14  |  43KB  |  987 lines
  1.  
  2.  
  3.  
  4.               The Main Complex and The SHC Editor's BBS's
  5.                             Proudly present
  6.  
  7.             OPERATION OVERKILL II CHALLENGE TOURNAMENT GAME
  8.                     By Donna Murrell and Paul Fusco
  9.  
  10.  
  11. PURPOSE OF THIS FILE:
  12.  
  13. This document is intended to help Sysops set up a Challenge Tournament
  14. game of Operation Overkill II, v997b, written by Dustin Nulf and Tom
  15. Hazel, between 2 BBS's.  It is assumed that you have an advanced
  16. knowledge of your BBS software, front end mailers, and batch file
  17. operation and setup.  For the purpose of this discussion I will use my
  18. software names as an example but with proper modification, this setup
  19. will apply to most systems.  Do not feel that this set up is the only
  20. way to accomplish this task.  Feel free to modify it any way it works
  21. for you and by all means, if you find any shortcuts, I can be reached
  22. via Fido NetMail 1:202/727 or Donna at 1:387/617.  Both Donna and I
  23. also monitor the FidoNet Echos - OOII and OKILLERS.
  24.  
  25.  
  26.  
  27. SOFTWARE AND UTILITIES REQUIRED:
  28.  
  29.      1. BBS software <ie. WILDCAT, QuickBBS>
  30.      2. Operation Overkill II game <preferably v997B>
  31.      3. Front end mailer software <ie. FrontDoor>
  32.      4. Packing/unpacking software <ie. Pkzip 110>
  33.      5. Utility for auto generating NetMail file transfer <ie. XROBOT>
  34.      6. Flag file <any ASCII text file of 1 or more bytes>
  35.         This file should reside in the OOII game directory.
  36.  
  37.  
  38.  
  39. OVERVIEW:
  40.  
  41. The Operation Overkill II <OOII> Challenge Tournament is a game of OOII
  42. played between two or more different BBS's.  Each board would set up an
  43. identical game to the others.  Using the same maps and proper OOCONFIG
  44. options.  Only the OOCONFIG options unique to an individual board will
  45. differ, such as the name of the bbs, video screen output etc.  The game
  46. begins on one board and is played for an agreed amount of time then the
  47. *.OO files are packed and sent to the next board.  The next board in
  48. turn keeps and plays the game for the same amount of time and passes
  49. the *.OO files to the next board in turn or back to the original board.
  50. This process is continued until the game is won. <The death of
  51. OVERKILL>.
  52.  
  53. The recommended amount of time the game spends on one board should not
  54. be less than 1 day and should not exceed three days.  Consideration
  55. should be given to long distance charges if the BBS's are not in the
  56. same dialing area.  Options for the two day game will be discussed
  57. here.  We chose a 2 day operation for a few different reasons, but
  58. mainly because of Long distance charges and in order for the players to
  59. enjoy the game.  This can be a popular game so it's important to allow
  60. enough time for your users to get a chance in the game.  More than that
  61. we felt they would get bored while the game was at the opposing BBS
  62. site.
  63.  
  64.  
  65.  
  66. GROUND RULES:
  67.  
  68. This section refers to some Ground Rules that should be discussed and
  69. agreed upon by all sysops involved in the game.  Go over them carefully
  70. before initiating a Challenge Game and make sure these options have
  71. been covered.  Included are some suggestions we find helpful.
  72.  
  73. Running MAINTOO:
  74. The running of MAINTOO, the OOII maintenance program, should take place
  75. either just before the transfer of the game files from one board to
  76. another or just after the transfer.  We suggest each board run MAINTOO
  77. before the packing and sending of the OO_FILES.ZIP file.  Mine is
  78. include in the :MAINT TODAY.BAT.  In some zone changes, a sysop will
  79. not be able to run the program before the transfer.  This should be
  80. discussed before the game begins with all sysops to insure proper
  81. running of the game maintenance.  Failure to run MAINTOO before a user
  82. logs on will result in a long delay for the user while MAINTOO runs.
  83. Running MAINTOO twice will cause unfair gains to some users and losses
  84. to others.  As with the timing <discussed later>, this step should be
  85. planed well between sysops.
  86.  
  87. Teams:
  88. Due to the nature of this game being played on multi boards, teams are
  89. strongly recommended.  Teams can be drafted in different ways.  Either
  90. board against board, or random drawing.  If the game is board against
  91. board, consideration will have to be given to any players who are
  92. members of both boards.  In the case of Long distance, this may not be
  93. much of a problem but if the game is local calls to both boards, some
  94. limitations may need to be set.  Even in this type of game, teams may
  95. need to be defined.  In other words, some users may need to make up
  96. their minds which board they wish to represent.  Some restrictions may
  97. need to be imposed such as security level changes etc. to keep players
  98. from taking advantage of local situations.
  99.  
  100. In a board against board game, only members of that team should be
  101. allowed to play.  In a random drawing, members of both teams will be
  102. allowed to play while the game is on either board but any players that
  103. are members of both boards should be restricted to play on one board
  104. only.  This is an option that should be agreed to by all sysops.
  105.  
  106. Maps:
  107. Dustin Nulf and Tom Hazel are doing everything in their power to make
  108. OOII as challenging as possible.  The result of their labor is a game
  109. that keeps getting better and better.  There is also a lot of
  110. controversy over whether maps should be available or not.  With the
  111. addition of the ability to print the maps, this is another
  112. consideration that will need to be agreed upon by the sysops.  The
  113. designers of this Challenge concept appreciate greatly the ability to
  114. print these maps and hope this option will remain in future versions of
  115. OOII and the editor.  But this option is at the discretion of the
  116. sysops in a Challenge game.  If the game is local we suggest using maps
  117. other than the maps included with the OOII package and make up your own
  118. minds as to whether or not you offer them to the players.  But if the
  119. game is being played long distance, keep in mind, it's your dime.  We
  120. still recommend using maps other than the stock maps, but strongly
  121. suggest you offer them to the users for download.  The speed of the
  122. game is determined on the amount of information the players have at the
  123. onset of their play.  The more they know, the faster they play.  The
  124. speed of the game and the option to download the maps should be agreed
  125. upon before the start of the game.
  126.  
  127.  
  128.  
  129. SETTING UP THE GAME: <Using Wildcat 3.xx and FrontDoor 2.02>
  130.      See below for example using QuickBBS and FrontDoor 2.02.
  131.  
  132. It is assumed that you already have a fully operational BBS system and
  133. front end mailer, so the first step is going to be setting up the game.
  134. Since both sysops will have control of the game and editor, trust is a
  135. given.  It's advisable to play with a board you know and are confident
  136. with.
  137.  
  138. 1. If you're not familiar with OOII as a door game, I'll leave it up to
  139. you to unpack game and docs and go over the setup on your own.  This
  140. Challenge game is not intended for a board installing OOII for the
  141. first time.  We suggest you run a few games on your board to become
  142. familiar with set up and play and generate some interest in users.
  143. Assuming you're familiar with the setup, the first thing to do is
  144. install the door game as you would any other OOII game on your system.
  145. Set up directories and put the game files there.
  146.  
  147. 2. Run OOCONFIG.  Each board should run OOCONFIG and set the options
  148. for each particular system.  Just as you normally would.  The option
  149. for the sysop's name should be SYSOP.  The sysops password should be
  150. agreed upon by both/all sysops and should remain throughout the game.
  151. A minimum of 60 minutes playing time should be set and at least 6 but
  152. no more than 12 hours between log ins.  Consideration should be given
  153. here to the amount of time the game will be on each board and the
  154. number of players in the game.  All options other than system options
  155. <name of BBS, Bulletins, etc.> should be set EXACTLY THE SAME ON ALL
  156. BOARDS.
  157.  
  158. The following is a copy of my OOCONFIG.DAT.  This file is created and
  159. can be edited with OOCONFIG.EXE.  It is an ascii file so it can also be
  160. edited with any text editor.  Refer to the OOII documentation for
  161. detailed explanations of each option.  Here, we will discuss options
  162. for the Challenge game only.
  163.  
  164.      D                               ; Video screen output
  165.      6                               ; Hours between calls
  166.      SYSOP                           ; Sysops handle
  167.      QIBWAAI HQ                      ; Name of complex building
  168.      60                              ; Minutes per player in game
  169.      QIBWAAI                         ; File name of maps
  170.      38                              ; Action combat delay
  171.      Y                               ; Fossil driver installed
  172.      N                               ; Multi-node BBS
  173.      SYSOP                           ; Sysops name
  174.      The SHC Editor's BBS            ; BBS
  175.      REGISTRATION                    ; Registration code
  176.      C:\WILDCAT3\BULL\BULL38.SCR     ; Color top 10 path
  177.      C:\WILDCAT3\BULL\BULL38.BBS     ; Ascii top 10 path
  178.  
  179. Video screen output, Fossil driver, multi-node, BBS name, and
  180. registration should be set up on both boards exactly like they would be
  181. if the board was playing an in-house game.  Use the option information
  182. that works on your system.  USE YOUR OWN REGISTRATION.  It is illegal
  183. for two boards to use the same code nor is it necessary.  The game will
  184. run fine with different information entered in these options.  This
  185. type of game is designed for registered boards so if you're running a
  186. non-registered version, REGISTER IT!!!
  187.  
  188. The Sysops Handle, and Sysops Name are the only configuration options
  189. entered permanently in the USERFILE.OO so the name of any sysop here
  190. will give that person full control of the game.  We STRONGLY suggest
  191. you enter SYSOP in both of these options on all boards.  When the Sysop
  192. wants to log on and play the game, they use REAL NAMES, then create a
  193. handle for that sysop as a normal player.  Ie. When Donna or I play we
  194. log on as Donna Murrell or Paul Fusco.  Logging on as SYSOP would cause
  195. serious concern among the players.  This will also avoid confusion in
  196. the USERFILE.OO file.  A password will be asked for when OOCONFIG is
  197. exited and the game reset.  This password should be agreed upon by all
  198. sysops and remain throughout the game.  The involved sysops should
  199. enter the game as SYSOP only if there is a DEFINITE need, ie. trouble
  200. with the game, runtime errors, corrupted files etc.  Never to play the
  201. game.
  202.  
  203. Hours between calls, minutes per player, and combat action delay are
  204. all options that should be agreed upon by all sysops.  There are as
  205. many different boards as there are sysops and not all boards allow the
  206. same amount of time for users to log on every day.  We find on most
  207. game boards that 2 hours with 30 to 60 minutes in doors is average.  We
  208. suggest between 6 and 12 hours between calls, 60 minutes minimum per
  209. player, and combat action delay set at 35-40.  These options should be
  210. identical on all boards.
  211.  
  212. Name of complex building and file name of maps are both options that
  213. should be agreed upon.  These options should be identical on both
  214. boards.  If maps are changed during the game, they should be changed on
  215. both boards for the same amounts of time.  Careful changing maps :)
  216.  
  217. The top 10 listings are very important in a game of this nature.  See
  218. the discussion on Bulletins below for more detail on the listing.
  219.  
  220. 3. Run MAINTOO on all boards.  The board that is going to have the
  221. first turn should run MAINTOO and begin the game at the specific
  222. starting time.  Just as you would any other game of OOII.  The other
  223. boards should run MAINTOO and at that point delete all the *.OO files
  224. in their game directory.  The *.OO files are the data files for the
  225. game.  If all the OOCONFIG options are set correctly and the same maps
  226. are being used on each board, these files will be passed from one board
  227. to the other and there should be no interruptions or problems with
  228. running the game on the other boards.
  229.  
  230. 4. Play OOII for n <2 in this case> days.  The first board plays for
  231. it's full turn of days then the *.OO files should be packed and sent
  232. via net mail to the next board.  The next board in turn unpacks the
  233. files and puts them in the OOII directory and opens play.  Each board
  234. in turn repeats the process for its alloted amount of time.
  235.  
  236.  
  237.  
  238. TRANSFERRING THE FILES:
  239.  
  240. Now the tricky part begins.  Once a boards turn is completed it's time
  241. to pass the files on to the next board.  This should be done as quickly
  242. as possible so all players will get as fair a chance as possible.  This
  243. can be done manually or automatically.  If you're an ambitious Sysop
  244. and don't mind spending a few minutes packing and shipping it's pretty
  245. basic.  But if you're lazy like me <hence the name MACROman> you'll
  246. want to automate this process.  If you have a tendency to fall asleep
  247. on the sofa playing Nintendo then you BETTER automate the process.  The
  248. purpose of this section is to help you automate the process but a
  249. working knowledge of manual operation will certainly aid your setup.
  250. Especially if your system is not identical to mine.
  251.  
  252.  
  253. Manual operation:
  254. Once your board has finished it's turn the *.OO files should be packed
  255. up and shipped to the next board.  Using PKZip the command would be:
  256. pkzip <path and name of zip file> *.OO.
  257. Mine would read: PKZIP OO_FILES.ZIP *.OO
  258. This file should be placed where you make your netmail file transfers.
  259. Refer to your mailer documentation.  Once the file is packed, go into
  260. your front end mailer and generate a netmail message to send the file
  261. to the next BBS and ship it.  That's all there is to it.  The receiving
  262. BBS should now unpack the file and put all the *.OO files in the OOII
  263. tournament game directory.  The game is now ready to play on the next
  264. board.
  265.  
  266. *** NOTE ***  Not all BBS softwares are alike in the handling of
  267. missing door files.  It's a good idea to turn off the door when it not
  268. on your board.  This will eliminate any un-necessary crashes because
  269. the BBS can not find the door batch or the game files.  On a system
  270. that runs doors from a batch file, rename the batch file and in most
  271. cases that will be suficient.
  272.  
  273. Automated operation:
  274. If you're a sysop with lots of time on your hands, the manual operation
  275. is the way to go.  But since these files are better transferred late at
  276. night and very early in the morning, most of us don't have time to wait
  277. around and pack, ship and receive files.  After all, what good are
  278. computers and software if we have to sit there and do all the work.
  279. This section is to help you automate your system to handle all the non-
  280. play time tasks.  Now sit back, get a soda and read this a couple
  281. times.  I'll give examples of WILDCAT, FRONTDOOR set up but it should
  282. be easy enough for you to modify this configuration to your own system.
  283.  
  284. Just like any other off-line maintenance <ie. MAINTOO> the automation
  285. of this task is accomplished by two timed, forced nightly events.  This
  286. example will use errorlevels and batch files.  Most BBS software
  287. require an errorlevel to run an external maintenance so that's where
  288. we'll start.
  289.  
  290. The following batch file lines are the lines I have included in my
  291. RUNBBS.BAT file which runs my entire system.  Only the lines having to
  292. do with the OOII set up will be presented and discussed here.  Each
  293. label will be discussed in detail at the end of the batch file example.
  294. This example is set up for a two day turn on each board.
  295. -----------------------------------------------------------------------
  296.      :BACK_2_FD
  297.       CTTY CON
  298.       SET WCPORTID=1
  299.       C:
  300.       CD \FD
  301.       CLS
  302.       FD
  303.       IF ERRORLEVEL 100 GOTO MAINT
  304.       IF ERRORLEVEL 99 GOTO MAINT2
  305.       IF ERRORLEVEL 95 GOTO 2_THE_CAT
  306.       IF ERRORLEVEL 85 GOTO LOCAL_FD_2_CAT
  307.       GOTO OFF_OR_DOWN
  308.  
  309.      :MAINT
  310.       C:
  311.       CD \wildcat3
  312.       CALL today.BAT
  313.       IF EXIST D:\WILDCAT\DOOR\OOIITOUR\NO.DOC GOTO NO
  314.       IF EXIST D:\WILDCAT\DOOR\OOIITOUR\YES.DOC GOTO ZIP
  315.       GOTO BACK_2_FD
  316.  
  317.      :MAINT2
  318.       IF EXIST C:\FD\FILE\OO_FILES.ZIP GOTO UNZIP
  319.       GOTO BACK_2_FD
  320.  
  321.      :UNZIP
  322.       C:
  323.       CD \FD\FILE
  324.       PKUNZIP OO_FILES.ZIP D:\WILDCAT\DOOR\OOIITOUR
  325.       COPY OO_FILES.ZIP C:\TEST\HOLD\INCOMING.ZIP
  326.       DEL OO_FILES.ZIP
  327.       CD \WILDCAT3
  328.       REN DOOR6.OUT DOOR6.BAT
  329.       CD \WILDCAT3\DISPLAY
  330.       COPY HELLO3.IN HELLO3.BBS
  331.       D:
  332.       CD \WILDCAT\DOOR\OOIITOUR
  333.       COPY FRONTIER.OO C:\WILDCAT3\BULL\BULL39.BBS
  334.       MAINTOO
  335.       REN TEST.DOC NO.DOC
  336.       GOTO BACK_2_FD
  337.  
  338.      :NO
  339.       D:
  340.       CD \WILDCAT\DOOR\OOIITOUR
  341.       REN NO.DOC YES.DOC
  342.       GOTO BACK_2_FD
  343.  
  344.      :ZIP
  345.       D:
  346.       CD \WILDCAT\DOOR\OOIITOUR
  347.       PKZIP OO_FILES.ZIP *.OO
  348.       DEL *.OO
  349.       REN YES.DOC TEST.DOC
  350.       C:
  351.       CD \WILDCAT3
  352.       REN DOOR6.BAT DOOR6.OUT
  353.       CD \WILDCAT3\DISPLAY
  354.       COPY HELLO3.OUT HELLO3.BBS
  355.       CD \FD
  356.       XR SEND D:\WILDCAT\DOOR\OOIITOUR\OO_FILES.ZIP 1:387/617
  357.       GOTO BACK_2_FD
  358.  
  359.      :OFF_OR_DOWN
  360.       ECHO ATM0H1 > COM1
  361.       C:
  362.       CD C:\
  363.       CLS
  364. -----------------------------------------------------------------------
  365. Label block 1 - :BACK_2_FD
  366.  
  367. The first 7 lines of this block are the lines that bring up the system
  368. and return to the BBS any time the BBS is exited or swapped out for any
  369. reason.  Refer to your BBS/Mailer documentation for further
  370. explanation.
  371.  
  372.      :BACK_2_FD
  373.       CTTY CON
  374.       SET WCPORTID=1
  375.       C:
  376.       CD \FD
  377.       CLS
  378.       FD
  379.  
  380.  
  381. The next 5 lines direct the system where to go whenever an errorlevel
  382. exit is detected.  Errorlevels 99 and 100 are my nightly events.  These
  383. labels <MAINT and MAINT2> are the keys to the automation of the OOII
  384. tournament game file transfers.  Refer to the dos manual for errorlevel
  385. operation.
  386.  
  387.       IF ERRORLEVEL 100 GOTO MAINT
  388.       IF ERRORLEVEL 99 GOTO MAINT2
  389.       IF ERRORLEVEL 95 GOTO 2_THE_CAT
  390.       IF ERRORLEVEL 85 GOTO LOCAL_FD_2_CAT
  391.       GOTO OFF_OR_DOWN
  392. -----------------------------------------------------------------------
  393. Label block 2 - :MAINT
  394.  
  395. This block runs every night on my system at 12:03 am PST.  The first 4
  396. lines of this block are the lines that run all my nightly maintenance
  397. for games <MAINTOO, TWARS, GLOBAL WARS, etc.>, files lists, etc.
  398. These are included in the file TODAY.BAT and are of no consequence
  399. here.
  400.  
  401.      :MAINT
  402.       C:
  403.       CD \wildcat3
  404.       CALL today.BAT
  405.  
  406. The next two lines tell the system to look for the flag file in the
  407. OOII directory.  These lines are active only when the game is on my
  408. system.  The flag file is necessary to count days from receiving to
  409. shipping and what days are "no action" days.  This file is a simple
  410. ASCII file <mine just says "HELLO"> to tell the system which day it is
  411. and what action is to be taken.  The name of this file is the ONLY
  412. important thing about it.  Automatic receiving or sending the
  413. OO_FILES.ZIP file depends on the name of the flag file.  When the
  414. proper name condition of the flag file is met the proper action is
  415. taken.  When the game is NOT on my board and in a dormant condition,
  416. this file is named TEST.DOC.
  417.  
  418. When the OO_FILES.ZIP file has been received from another board and
  419. recognized by the label :MAINT2, the flag file is renamed by a command
  420. line in the batch file to NO.DOC.
  421.  
  422. The existence of the NO.DOC file tells the system that no action is to
  423. be taken on the OOII files on the current maintenance event.  When the
  424. NO.DOC file is recognized by the first IF EXIST line it will pass
  425. control to the label :NO and the flag file will be renamed YES.DOC.
  426.  
  427. When the YES.DOC file is recognized by the second IF EXIST line, it
  428. tells the system that with this event the *.OO files should be packed
  429. for shipment <OO_FILES.ZIP> and all the *.OO files in the OOII
  430. directory deleted.
  431.  
  432.       IF EXIST D:\WILDCAT\DOOR\OOIITOUR\NO.DOC GOTO NO
  433.       IF EXIST D:\WILDCAT\DOOR\OOIITOUR\YES.DOC GOTO ZIP
  434.       GOTO BACK_2_FD
  435. -----------------------------------------------------------------------
  436. Label block 3 - :MAINT2
  437.  
  438. This block runs every night on my system at 2:01 am PST at the end of
  439. Zone Mail Hour.  It checks the FrontDoor file directory to see if the
  440. OO_FILES.ZIP file has been received from the next BBS.  If it finds it
  441. there, it passes control to the label :UNZIP <explained later>.
  442.  
  443.      :MAINT2
  444.       IF EXIST C:\FD\FILE\OO_FILES.ZIP GOTO UNZIP
  445.       GOTO BACK_2_FD
  446. -----------------------------------------------------------------------
  447. Label block 4 - :UNZIP
  448.  
  449. Confused yet???  Well here's where the fun begins.  If you're not
  450. confused, refill that soda and get a pencil.  Now you may need to draw
  451. some lines back up the page to refer from here...  Ready???
  452.  
  453. This block is the action take by the system when the condition of
  454. :MAINT2 is met.  This means that the OO_FILES.ZIP has been received by
  455. your board and :MAINT2 has found it.  Control of the batch file is now
  456. passed here to :UNZIP.
  457.  
  458. The first 4 lines find and unpack the received OO_FILES.ZIP to the
  459. proper game directory.
  460.  
  461.      :UNZIP
  462.       C:
  463.       CD \FD\FILE
  464.       PKUNZIP OO_FILES.ZIP D:\WILDCAT\DOOR\OOIITOUR
  465.  
  466. This line just copies the OO_FILES.ZIP to somewhere else on my hard
  467. drive so I'll have a backup if anything happens.  <why should anything
  468. happen ... grin>
  469.  
  470.       COPY OO_FILES.ZIP C:\TEST\HOLD\INCOMING.ZIP
  471.  
  472. This one just deletes the file so it won't be recognized again.
  473.  
  474.       DEL OO_FILES.ZIP
  475.  
  476. The next 2 lines are the switch that turn the door on and off.  If
  477. Wildcat can't find DOOR6.BAT it will tell the user on-line that the
  478. door option for this game is not available.  This line turns it on.
  479.  
  480.       CD \WILDCAT3
  481.       REN DOOR6.OUT DOOR6.BAT
  482.  
  483. The next 2 lines activate a log in message to the on-line user telling
  484. them immediately whether or not the game is available.
  485.  
  486.       CD \WILDCAT3\DISPLAY
  487.       COPY HELLO3.IN HELLO3.BBS
  488.  
  489. The next 3 lines copy the Frontier log to a bulletin so it can be read
  490. easily by on-line users before they play the game.  This will tell them
  491. what went on while the game was in another city or board for 2 days.
  492.  
  493.       D:
  494.       CD \WILDCAT\DOOR\OOIITOUR
  495.       COPY FRONTIER.OO C:\WILDCAT3\BULL\BULL39.BBS
  496.  
  497. This line runs the OOII maintenance program.  This line is optional
  498. depending on the ground rules set up before the game <discussed
  499. previously>.
  500.  
  501.       MAINTOO
  502.  
  503. Finally the flag file will need renamed to let the system know what
  504. action to take with the running of the NEXT nightly maintenance event.
  505. In this case, the file has just been received so the flag is renamed
  506. NO.DOC to let the system know that no action will be taken in the game
  507. or to the game files in the next nightly event. It is only to rename
  508. the flag file.
  509.  
  510.       REN TEST.DOC NO.DOC
  511.       GOTO BACK_2_FD
  512. -----------------------------------------------------------------------
  513. Label block 5 - :NO
  514.  
  515. When the flag file NO.DOC is recognized by the label :MAINT, control is
  516. passed to this block.  This label does nothing more than find and
  517. rename the flag file to YES.DOC.  This tells the system on the NEXT
  518. nightly maintenance event the files will need shipped with that event.
  519.  
  520.      :NO
  521.       D:
  522.       CD \WILDCAT\DOOR\OOIITOUR
  523.       REN NO.DOC YES.DOC
  524.       GOTO BACK_2_FD
  525. -----------------------------------------------------------------------
  526. Label block 6 - :ZIP
  527.  
  528. When the condition of the flag file is YES.DOC and met by the :MAINT
  529. label, control is passed to this block.  This block packs the *.OO
  530. files, deletes them, turns off the door switch, and activates the log
  531. in message that the game is no longer available.
  532.  
  533. The next lines, pack all the game files <*.OO> into the OO_FILES.ZIP
  534. then delete the *.OO files from the game directory.  It's a good idea
  535. to keep a copy of OO_FILES.ZIP in case there's a problem with file
  536. transfers or whatever.  <What could go wrong???>
  537.  
  538. *** NOTE ***  Deleting the *.OO files before the game returns to your
  539. board is IMPORTANT.  If the *.OO files are found by PKZIP when it
  540. unpacks the OO_FILES.ZIP, it will ask you if you want to overwrite the
  541. existing file.  You may think you're going to wake up and play the game
  542. and find your computer sitting in PKZIP at a dos prompt waiting for a Y
  543. or N answer.  This could have a negative effect on the idea of
  544. AUTOMATING this system.   DELETE THE *.OO FILES BEFORE THE GAME RETURNS
  545. TO YOUR BOARD.
  546.  
  547.      :ZIP
  548.       D:
  549.       CD \WILDCAT\DOOR\OOIITOUR
  550.       PKZIP OO_FILES.ZIP *.OO
  551.       DEL *.OO
  552.  
  553. This line renames the flag file to TEST.DOC and tells the system that
  554. nothing is to be done until the return of OO_FILES.ZIP.  Now none of
  555. the conditions of :MAINT and :MAINT2 will be met until the OO_FILES.ZIP
  556. returns to this board
  557.  
  558.       REN YES.DOC TEST.DOC
  559.  
  560. The next 3 lines turn OFF the door batch file.  This will echo a
  561. message to any on-line user that chooses this game door that it's not
  562. available today.
  563.  
  564.       C:
  565.       CD \WILDCAT3
  566.       REN DOOR6.BAT DOOR6.OUT
  567.  
  568. These lines activate a log in message to on-line users that the game is
  569. not on this board and not available.
  570.  
  571.       CD \WILDCAT3\DISPLAY
  572.       COPY HELLO3.OUT HELLO3.BBS
  573.  
  574. For the next part of this batch file, you may need an additional
  575. utility.  These lines automatically generate a NetMail file attached
  576. message to the board that the game is going to next.  This example is
  577. using XROBOT and will generate the message and file attachment
  578. automatically.  Refer to the documentation of the utility you're using
  579. for the proper command line options.  If you do NOT have a utility, the
  580. NetMail message will need to be manually entered.  This is critical
  581. because failure to generate the NetMail message will cause the file
  582. OO_FILES.ZIP not to be passed on time and will cause delays in the
  583. game.
  584.  
  585.       CD \FD
  586.       XR SEND D:\WILDCAT\DOOR\OOIITOUR\OO_FILES.ZIP 1:387/617
  587.       GOTO BACK_2_FD
  588. -----------------------------------------------------------------------
  589. Timing:
  590.  
  591. Timing refers to the actual transfer of the OO_FILES.ZIP file.  It
  592. should be noted the times for the :MAINT and :MAINT2 labels allow 2
  593. hours between the time :MAINT finishes and :MAINT2 runs.  The transfer
  594. should take place in this time space with plenty of time for it to
  595. finish before :MAINT2 needs to run.  If :MAINT2 runs and the
  596. OO_FILES.ZIP file has not yet been received, the file will sit there
  597. until the next days maintenance and a complete day will be lost.  This
  598. is not much of a problem if the Challenge game is being played locally
  599. but if there's a time zone change, special considerations will need to
  600. be made.  Be sure all sysops involved plan the transfers of this file
  601. carefully so this file is always sent/received between the running of
  602. the :MAINT and :MAINT2 events.
  603.  
  604. *** NOTE ***  If any or all the boards this game is being played are on
  605. are busy boards, a second or even third event can be set up to re-run
  606. :MAINT2.  This will insure that if the file gets transfered late, the
  607. game will still be recognized and set up to give players maxium amount
  608. of time to play.
  609.  
  610. That's all there is to the automation.  I know that's a lot but lets
  611. try to put it all in perspective.
  612.  
  613. EXAMPLE:
  614.  
  615. Ok, you're the board initiating the play of the game.  Assuming your
  616. board and mine have set everything up properly this is what will
  617. happen.
  618.  
  619. Day 1: <after maintenance events have been run>
  620.  
  621.      You have all the OOII game files and the *.OO data files in your
  622.      directory and your flag file is set to NO.DOC.  REMEMBER TO NAME
  623.      YOUR FLAG FILE NO.DOC IF YOU'RE STARTING THE GAME.  Your door is
  624.      on and you play the game all day.
  625.  
  626.      On my end I have a directory with the all the game files except
  627.      the *.OO files and my flag file is set to TEST.DOC.  My door is
  628.      off.
  629.  
  630. Day 2:
  631.  
  632.      Your first nightly event :MAINT runs at 12:03 am and found the
  633.      condition of the flag file as NO.DOC.  Control is passed to :NO
  634.      and the flag file is renamed YES.DOC.  You continue to play the
  635.      game the second day.  Your second event :MAINT2 does not find it's
  636.      condition met so no action is taken in that event.
  637.  
  638.      On my end, none of the conditions were met in either event so no
  639.      action was taken.
  640.  
  641. *** NOTE ***  :MAINT is set to is 12:03 am and :MAINT2 is set at 2:00
  642. am.  This is to allow the file to be passed and then recognized by
  643. :MAINT2 on the other end.  Keep in mind, if different time zones are
  644. involved, consideration will need to be given to the timing.  Timing is
  645. discussed previously.
  646.  
  647. Day 3:
  648.  
  649.      Your first nightly event :MAINT has recognized the condition of
  650.      the flag file as YES.DOC and packs the files, ships the files, and
  651.      turns off the door switch.  The flag file is renamed TEST.DOC and
  652.      puts the system in dormant condition until the return of the
  653.      OO_FILES.ZIP to your board.  You can no longer play the game.  The
  654.      :MAINT2 event has not found its condition so no action is taken.
  655.  
  656.      Now it's my turn <if I've received the file between my :MAINT and
  657.      :MAINT2 nightly events>...  My first nightly event :MAINT, finds
  658.      no conditions met so no action is taken.  Then the file is
  659.      received from your system.  My second nightly event :MAINT2 has
  660.      recognized the condition of the presence of the OO_FILES.ZIP and
  661.      unpacks the file, routes the game files to the proper directory,
  662.      turns the door on and saves the file.  The flag file is renamed to
  663.      NO.DOC.  Now we play through day 3.
  664.  
  665. *** Note ***  Make sure you have previously deleted the *.OO files or
  666. your UNPACK will hang there waiting for YOU to answer Yes/No to
  667. overwriting the existing *.OO files).
  668.  
  669. Day 4:
  670.  
  671.      None of the conditions have been met in your events so no action
  672.      is taken.
  673.  
  674.      On my end the NO.DOC condition has been recognized by my first
  675.      nightly event :MAINT and the only action taken is renaming the
  676.      flag file to YES.DOC.  The :MAINT2 event finds no conditions met
  677.      and takes no action.
  678.  
  679. Day 5:
  680.  
  681.      On your :MAINT event run, nothing will happen because no
  682.      conditions have been met.
  683.  
  684.      On my end, the YES.DOC condition has been recognized by my first
  685.      nightly event :MAINT and the files are packed and shipped back to
  686.      you.  The flag file is renamed TEST.DOC and the system is dormant
  687.      again.  The :MAINT2 event will find no conditions met and no
  688.      action is taken.
  689.  
  690.      Now on your end, the running of your second nightly event :MAINT2,
  691.      OO_FILES.ZIP has been recognized and the files are unpacked and
  692.      routed to your proper directory, the switch is turned on, the flag
  693.      file renamed and you're back in play mode and we're back to Day 1.
  694.  
  695. *** NOTE ***   This setup is for a challenge game of 2 days on each
  696. board.  The number of days is determined by the number of name changes
  697. of the flag file.  The flag file must change names 1 more time than the
  698. number of days you wish to have the game on each board.  If it's a 1
  699. day game, the flag file will need 2 re-namings.  If it's 3 day turns,
  700. the flag file will need 4 re-namings.  This file is nothing more than a
  701. means to count down the days from receiving the game to sending it
  702. back.  Remember, each name change will need a separate :LABEL in the
  703. batch file.  Each :LABEL will need to rename the flag file to the next
  704. day's :LABEL.
  705.  
  706.      NO.DOC = 2 days to shipping
  707.      YES.DOC = 1 day to shipping
  708.      TEST.DOC = game shipped and waiting...
  709.  
  710.  
  711. SOME OTHER SUGGESTIONS:
  712.  
  713. Bulletins:
  714.  
  715. Being a games board I appreciate the ability to be able to log on, look
  716. at the others that have logged on and played certain games, what
  717. happened in the games, who's turn it is etc, without having to log into
  718. the games themselves.  For this reason I make max use of bulletin
  719. generators and the dos copy command.  In a game like this, players are
  720. going to want to keep a constant eye on what's happening.  Even if
  721. they're out of time in the game or out of turns they will be logging on
  722. to check stats.  By making use of the bulletin generator in OOII and
  723. copying the frontier log <FRONTIER.OO> to a bulletin, I find that users
  724. that want to check stats can get on, get the information, and get off
  725. again as quickly as possible.  This frees up the board for more time
  726. for other users to log on and play.  We suggest using the OOII top 10
  727. generator to create stats bulletins and copying the FRONTIER.OO file to
  728. a bulletin each time a user logs out of the game.  You can also use a
  729. file viewer option, if you have one, to view the frontier log from
  730. outside the game.
  731.  
  732. Log on screens and door menus:
  733.  
  734. Ok, now that you're a pro at the OOII Challenge Game, here's one other
  735. suggestion that will bring out your creative talents.  I have 2 log on
  736. screens that tell the users when they first get on the board whether or
  737. not the game is up and available or on the other board and not
  738. available, HELLO3.IN and HELLO3.OUT.  These are arranged so that when
  739. the label :ZIP is run, the HELLO3.OUT screen is activated and the users
  740. know right away the game is not available.  Like wise for HELLO3.IN
  741. when the label :UNZIP is run.  I have the same setup for the DOORS
  742. MENU, DOORS.IN and DOORS.OUT.  Activating this type of a file will
  743. depend on what file names your BBS displays and from where.  To
  744. activate them, put them in your display directory by names not
  745. recognizable to your BBS software, and add COPY commands in your :ZIP
  746. and :UNZIP labels to copy the appropriate file to the proper name to
  747. display the file.
  748.  
  749.  
  750.  
  751. SETTING UP THE GAME: <Using QuickBBS and FrontDoor 2.02>
  752.  
  753. Ok, One more time in a NutShell Overview, This is as concise
  754. as it gets:
  755.  
  756. 1.   Contact with challenging BBS needs to have been made and
  757.      Rules of play setup.  These are a few of the things that
  758.      need to be taken care of by the Sysops involved.
  759.  
  760.      Maps to use.
  761.      How many players per side.
  762.      Name of sysop in OOconfig file.
  763.      Name of transfer file that will be sent back and forth, etc.
  764.  
  765. 2.   If you have a MONSTER.DAT file that is different from the opposing
  766.      side, then that file should be either used on both boards or
  767.      deleted for the original.
  768.  
  769. 3.   A FrontEnd mailer is NECESSARY for automation of the shipment of
  770.      files to both BBS's involved in the game. This is to insure that
  771.      timing and ease of transfer is timely. (timing in this game is    
  772.      essential).
  773.  
  774. 4.   SETUP:  I use FrontDoor 2.02 therefore, that is the setup process
  775.      I will be explaining.
  776.  
  777.      Set Errorlevels in your batch file to load the board for ship-
  778.      ment of files, receiving files, and one for OFF night when there
  779.      is NO activity.
  780.      I will be explaining the 3 stages it goes through in order to get
  781.      from day one of the game, to # 3 when shipment of files will go
  782.      to the other board.
  783.  
  784. Example:
  785.  
  786.      If Errorlevel 175 Goto Maint
  787.      If Errorlevel 174 Goto NO  ;night that nothing happens
  788.      If Errorlevel 173 Goto UNPACK_OO  ;received files from OTHER BBS
  789.      If Errorlevel 172 Goto PACK_OO
  790.  
  791.      Identify these errorlevels something like:
  792.  
  793.      ; Zip files for shipment "to" remote BBS and generating
  794.      ; the message in XRobot in order to ship the files to
  795.      ; the remote location.  As you can see what we have done is
  796.      ; to rename ONE file, three different times.  On the night
  797.      ; the files are to be shipped, the file will be called YES.DOC
  798.      ; in order to tell your "If Exist" statement that it's the
  799.      ; night to go and zip up the files in the Overkill directory.
  800.      ;
  801.  
  802.      :PACK_OO
  803.      C:
  804.      CD \Doors\OOII
  805.      PKZIP C:\FD\FILE\OO_FILES.ZIP *.OO
  806.      DEL *.OO
  807.      REN YES.DOC TEMP.DOC
  808.      cd\qbbs\messages
  809.      SetFlag A8 OFF ALL
  810.      cd\qbbs\txt
  811.      copy arcade1.ans arcade.ans
  812.      copy arcade1.asc arcade.asc
  813.      cd\FD
  814.      CALL Robot.bat
  815.      GOTO Loop
  816.  
  817.     ;   The SetFlag function of QuickBBS is to disable user entry
  818.     ;   into that Door during the time the files reside at the
  819.     ;   other location.
  820.     ;
  821.     ;   Night when there is NO activity in shipment of files from
  822.     ;   either bbs, you should only rename the doc file residing
  823.     ;   in the Doors directory for the next nights shipment
  824.  
  825.  
  826.     :NO
  827.     C:
  828.     CD \Doors\OOII
  829.     REN NO.DOC YES.DOC
  830.     GOTO LOOP
  831.  
  832.  
  833.     ;Unzip files from shipment "from" remote BBS
  834.  
  835.     :UNPACK_OO
  836.     C:
  837.     CD \FD\FILE
  838.     PKUNZIP OO_FILES.ZIP C:\Doors\OOII
  839.     DEL OO_FILES.ZIP
  840.     C:
  841.     CD \Doors\OOII
  842.     REN TEMP.DOC NO.DOC
  843.     cd\qbbs\messages
  844.     SetFlag A8 ON ALL
  845.     cd\qbbs\txt
  846.     copy arcade2.ans arcade.ans
  847.     copy arcade2.asc arcade.asc
  848.     cd\fd
  849.     GOTO Loop
  850.  
  851.     ; The SetFlag in this position turns on the A8 Flag on ALL
  852.     ; users to enable entry to that door now that the files
  853.     ; have returned to your location.
  854.     ;
  855.     ; Below is the definition of the "If Exist" statements we
  856.     ; found to work.
  857.     ; This is what happens each night during your regular maint-
  858.     ; enance.  The "If Exist" statements go into the directory
  859.     ; looking for one of the *.doc files (that says only something like
  860.     ; "hello"), and renames the file for the next nights activity.
  861.     ; when it finds that statement in the Errorlevels, it then
  862.     ; goes to that set  "Errorlevel"  during maintenance.
  863.  
  864.  
  865.     :Maint
  866.     cd\fd
  867.     night.bat              ; just normal night maintenance
  868.     If Exist \doors\OOII\no.doc Goto NO
  869.     If Exist \doors\OOII\yes.doc Goto PACK_OO
  870.     If Exist \fd\file\OO_FILES.ZIP Goto UnPACK_OO
  871.     goto Loop
  872.  
  873.  
  874.  
  875. Explanation of these 3 named files: (I hope)
  876.  
  877. No.Doc =  This file will exist on the night that NO activity is
  878.           scheduled.  It simply RENAMES the No.Doc to Yes.Doc and goes 
  879.           on to the next nights events the following night.
  880.  
  881. Yes.Doc = This next night event will go to Pack_OO Errorlevel "IF" all
  882.           is going properly so far.  This mean that your NO.DOC was
  883.           renamed correctly to yes.doc during your night event and it's
  884.           your night to Ship the files.  The Errorlevel finds Yes.Doc,
  885.           Zips up the files in the designated directory and prepares
  886.           for XRobot to ship them.  It then Deletes the *.oo files so 
  887.           that when the shipment comes back into your bbs from Remote, 
  888.           it can unzip them in to the directory.  It is then renamed to
  889.           Temp.doc.
  890.  
  891. Temp.doc= Does nothing but wait for the shipment of OO_FILES.zip from
  892.           the remote BBS.  When the OO_Files.zip is found by your
  893.           system it goes to the UNPACK_OO statement Errorlevel you
  894.           defined.  Unzips it into the game directory, deletes the
  895.           zip file, and renames the temp.doc to NO.DOC and starts
  896.           the Loop over again.
  897.  
  898. As you can see, a number of things take place all at the same time, and
  899. that your timing and the remote BBS's timing are essential in the file
  900. transfers and what happens at BOTH ends of the game.
  901.  
  902. Since Paul explained the XRobot to you already I won't go into that one
  903. again!  ( He does this so well, Doesn't he? )
  904.  
  905.  
  906. 1.  In the OOCONFIG.EXE file the setup is important.
  907.     The first thing you must know about is the configuration of
  908.     the sysop player in the game.  It MUST be designated only
  909.     as "Sysop", NO HANDLE!  This is to ensure proper file
  910.     overwriting in shipment as there is a Sysop on both sides
  911.     of the shipment.  The UserFile.oo contains the player information
  912.     and your bbs sysop will be overwritten with each shipment.
  913.     So Sysop's, please set yourself a character of your own if
  914.     you plan on playing as all. Next is the name of the building
  915.     in the game.  It must be the same on both ends.  The only
  916.     difference you will have will be in the registration number
  917.     and file names for ansi/Ascii files, and name of the BBS.
  918.     Other than those, all other things will be the same.
  919.  
  920. 2.  Time limits:  (can vary but make sure BOTH sides have it
  921.     set to the same amount of time for fairness of play.)
  922.  
  923.     One hour in the game;  6 hour intervals;
  924.     Ship the files 2 days later.  Decide WHO is going to begin the
  925.     game and on what day so the configuration can be set.
  926.  
  927.  
  928.  
  929. CONCLUSION:
  930.  
  931. Now you're ready to enter the most challenging, and fun game you've
  932. ever played on a BBS.  We hope you enjoy the OPERATION OVERKILL II
  933. CHALLENGE TOURNAMENT GAME.
  934.  
  935.  
  936. THANKS TO:
  937.  
  938. Dustin Nulf and Tom Hazel for producing the best BBS Door game
  939. available.
  940.  
  941. All the people, sysops and users that inspired the concept of the OOII
  942. Challenge game.
  943.  
  944. All the players of the First National OOII Challenge game who helped
  945. prove the workability of this concept.  And for their patience when any
  946. problems arose.
  947.  
  948. Personal Notes:
  949.  
  950. (Paul Says)  And a special thanks to Donna Murrell and Mark Stroud who
  951. pushed me into this game and spent mega dollars in long distance
  952. helping set up this game and instructing less qualified players.
  953.  
  954. (Donna Says)  My thanks go out to Paul Fusco who agreed to set this up
  955. with me in the first place and spending long hours mulling over the
  956. setup and MULTIPLE NetMail shippings to get it the way we wanted it to
  957. be played.
  958.  
  959.  
  960. Questions, comments, suggestions, escape plans or complaints should be
  961. routed to:
  962.  
  963.           Donna Murrell                 Paul Fusco
  964.           The Main Complex BBS          The SHC Editor's BBS
  965.           512-658-8009                  619-563-1598
  966.           Fido 1:387/617                Fido 1:202/727
  967.  
  968.           Monitoring both OOII FidoNet echos, OOII and OKILLERS.
  969.  
  970.  
  971. DISCLAIMER
  972.  
  973. What we have explained here as a joint effort, does not mean that it
  974. is a sure thing and will work on your bbs setup.  This is simply
  975. a couple examples of what the two of us did in order to have a good
  976. time with the Overkill game, and let both sides enjoy the company and
  977. competition with another BBS.  We have both made some new and good
  978. friends out of this.
  979.  
  980. Good luck to all of you.  Hope to see you soon in YOUR OWN competition
  981. games.
  982.  
  983. ***** No spitting on the wastelands.*****
  984.  
  985. Paul Fusco and Donna Murrell
  986. (SHC Editor's, San Diego, CA and The Main Complex, Universal City, TX)
  987.